POV：字幕又對不上音軌了，你改了好幾輪切段邏輯還是漂，然後發現真正的問題是：你根本拿不到時間戳。

第五週最後一篇談 GPU，這是雲端選型最容易「情緒化」的一題：一聽到 GPU 就想開一台大機器養著，或看到價格什麼都不敢開。我用自己真的做過的選擇，liaostudio 的 Whisper 字幕 backend，把 Cloud Run GPU 跟 GKE GPU node pool 放在同一個秤上。

先說這個 workload 長什麼樣

Day 08 講過來龍去脈：liaostudio 的字幕時間戳會漂移。Day 08 寫的是我當時的判斷：以為是切段與靜音處理的問題，後續調整也都集中在那裡。換成自架的 Whisper GPU 引擎、拿到真實的 word timestamps 之後回頭看，那些調整其實是在繞過一個更底層的限制：當時用的轉寫路徑拿不到內部時間戳，只能靠字數比例加靜音偵測去估。

順帶一提，我當時也先查過其他轉寫 API 有沒有提供 word-level 時間戳，沒有的直接排除。這跟今天的主題無關，但說明了：選 GPU 平台之前，先確定你要的功能在那個平台上存在。

這個 backend 的形狀很清楚：

• 一段音訊進來、推論、字幕出去，做完就結束，是 Day 21 說的 request-driven。
• 需要 GPU，但不是 24 小時都需要，我不是隨時在產字幕。
• 使用者本來就預期要等，冷啟動多的那一段可以接受。

選項一：Cloud Run GPU，我實際用的

我的專案已核准 L4 配額，所以 Whisper backend 直接上 Cloud Run 掛 L4。它跟上面三點一一對上：

• request-driven，就是 Cloud Run 的世界觀。
• 不是 24 小時都需要，沒請求就縮到 0，閒著的 GPU 不用付錢。
• 冷啟動可以接受，因為字幕本來就不是即時互動。

部署跟 Day 23 幾乎一樣，多三個旗標。L4 有硬性下限：官方文件寫明 L4 至少要 4 CPU 與 16 GiB 記憶體（建議 8 CPU 與 32 GiB），低於這個門檻部署會被拒絕（以下是示範值，不是我線上那份設定）：

gcloud run deploy whisper-gpu \
  --image=asia-east1-docker.pkg.dev/PROJECT_ID/agents/whisper-gpu:v1 \
  --region=asia-east1 \
  --gpu=1 --gpu-type=nvidia-l4 \
  --cpu=4 --memory=16Gi \
  --min-instances=0 --max-instances=1 \
  --concurrency=1 \
  --no-gpu-zonal-redundancy \
  --no-allow-unauthenticated

幾個值得注意的點：--concurrency=1 讓一個 instance 一次只處理一個請求，第二個請求會排隊等（配上 --max-instances=1，也不會另開一台來接）。我這樣設是因為推論會吃滿整張卡，硬讓兩個請求併行，我目前的理解是只會互相拖慢；--no-gpu-zonal-redundancy 是關掉跨 zone 的 GPU 備援，官方文件有說明它對可用性與計費的影響。價格不寫死，以官方定價頁為準。

代價也很直接：GPU 型號與可用 region 有限，如果你的模型需要比 L4 更大的卡，這條路可能就走不通；而且 Cloud Run 不能讓多個 workload 共用同一張卡。

選項二：GKE GPU node pool，我保留的

如果把 Whisper backend 放到 GKE，有兩種長相。Standard 是自己開一個 GPU node pool，節點你管、節點你付；Autopilot 是在 Pod 上宣告 nodeSelector: cloud.google.com/gke-accelerator: nvidia-l4 加 resources.limits: nvidia.com/gpu: 1，節點由 GKE 幫你開、按 Pod 宣告的資源計費（Day 22 提過）。下面的對照以 Standard 為主，它才是「自己養卡」的路，核心是掌控度：

• 同一張卡可以放多個 GPU workload，但不是預設就會共用：device plugin 預設是一個 Pod 拿整張 nvidia.com/gpu，要共用得另外設定 time-slicing 或 MIG 這類機制（官方文件有整理，我沒實際用過）。Cloud Run 連這個選項都沒有。
• 可以跑長時間、有狀態、需要 GPU 的東西：常駐的推論伺服器、Day 10 提的 training job，這些都不是 Cloud Run 的守備範圍。

代價同樣直接：Standard 是為節點付錢，不是為請求付錢。 GPU node pool 開著就在計費，除非你自己縮到 0；而縮到 0 之後再拉起來，我目前的理解是要等整台機器開機、裝 driver、拉 image，比 Cloud Run 的容器冷啟動慢，但我沒量過數字。對「偶爾用」的 workload 這是雙重懲罰：閒著在燒錢，要用時又要等。Autopilot 少掉養節點這層（Pod 刪掉就不再計費），但節點等級的等待還在，共用卡也仍要自己設。

我的決策表

以我現在這個 workload 來說，結論很清楚：偶發的字幕生成，Cloud Run GPU 比較合適。 但我把 GKE 留在表上，因為決策的變數從來不是「哪個技術強」，而是「手上有幾個 GPU workload、多常用」。這兩個數字一變，答案就會變。

一個提醒：不要因為「以後可能會有很多 GPU workload」就先開 node pool。Day 20 那張清單講過，為想像中的未來付錢，通常是雲端帳單失控的起點。

明天進入第六週，把視線從 GCP 轉到 Azure，先做 AKS 對 GKE 的概念對照。

今日一句話

GPU 選型不是挑規格，是看你多常需要它：偶發的靠 Cloud Run GPU 縮到 0 省錢，常駐或多個 workload 要共用卡，才值得為 GKE node pool 付常駐的錢。

延伸閱讀

• Cloud Run GPU 支援的型號、region、CPU 與記憶體下限：GPU support for services；價格以官方定價頁為準，這裡不抄數字
• GKE 上 GPU 的整體概念（Standard node pool 與 Autopilot 都涵蓋，Autopilot 的 nodeSelector 寫法從這頁往下找）：About GPUs in Google Kubernetes Engine (GKE)
• GKE 上多個 Pod 共用一張卡的幾種方式（time-slicing、MIG）：About GPU sharing strategies in GKE